Customization of Function Point Analysis at Nokia

-This paper describes a project to enhance SW project effort estimation at a SW production unit (SPU) within, Nokia Corporation. The SPU produces embedded SW for Nokia's DX200 telecom switches. Within that project the standard function types (EI, EO, EQ, ILF, EJF) of the original function point analysis (FPA) were replaced by selected elements of the Nokia's DX200 switching SW architecture. Data from 13 projects (out of over 40 available projects) was collected to be used for weight calibration, and statistical methods (e.g. regression analysis) were used to get the basic weights. Complexity determination is not used in the customized method, but functions are categorized into new, modified and removed classes. Six general characteristics, having clear impact to the effort, are used as productivity factors. These characteristics are specific to the SPU. The early results are very promising. The customized method has been taken into daily use in all new projects at the SPU. There is no extensive statistical data yet to compare actual data to estimates by the customized method. It seems, however, as if the SPU will achieve a significant improvement in estimation accuracy. INTRODUCTION Importance of accurate estimates in SW project planning and control is never emphasized too much. Also at Nokia there is a permanent need to improve accuracy of effort and duration estimates of SW projects systematically. This paper describes a project to enhance SW project effort estimation at a SW production unit (SPU) within Nokia Corporation. The SPU produces embedded SW for Nokia's DX200 telecom switches. The SPU had not applied function point analysis (FPA) earlier, but wanted to take a formal estimation technique based on FPA approa'ch into use in new SW projects. PROBLEMS WITH THE TRADITIONAL FPA The original FPA by Albrecht was selected as the basis. Very soon some problems were discovered, as follows: 1. The FPA count depends on how to define the system boundary. There are several alternatives how to define the boundary in the SPU's SW architecture. It is not clear which abstraction level would be the most suitable to be considered as the 'system'. 2. The identification of standard FPA function types (EI, EO, EQ, ILF, EIF) is not a trivial task, because the DX200 SW architecture is so visible in design and specification phases. The basic FPA counting is considered to cause too much variation to be reliable, behg too dependable on the person who counts. 3. There are some suspicions that standard FPA function types do not dlepict correctly all aspects of a real-time switching system as implemented. 4. It is also suspected that standard FPA does not result as accurate estimates in SW enhancement projects as in new SW development. FPA does not make any difference whether a function is new or modified. Collected experience suggests that there is a clear difference. 5. A preliminary study indicated that some SPU-specific systems characteristics (i.e. productivity factors) has to be added to the estimation model. Most IFPUG characteristics seemed to have no impact at all. On the other hand, according to our observations characteristics do not have an equal impact range, but clearly some characteristics at the SPU had larger impact than others. . 6. The FPA is also quite a laborious method when defining SW size, the main element in this sense being the complexity determination. It is not reasonable to add so much cost determining complexity when the function types are not self-evident. All these problems could certainly have been resolved to some extent, but an obvious question was put: why should the SPU adapt to FPA instead of adapting FPA to current concepts of the SPU's SW specification and design processes, and SW architecture? PROS AND CONS OF THE CUSTOMIZED FPA By customizing FPA we could easily overccme all problems mentioned above. A drawback is that we can not define SW size so early within the SW life-cycle than using traditional FPA, because of more concrete function types (as will be shown later). We assume that selecting more concrete function types results to more accurate estimates. Another potential drawback is the missed opportunity for benchmarking. Standard FPA is quite popular, and using a customized method we lose the ability to compare the SPU's productivity rates to public-domain FPA data. We can, however, make comparisons within Nokia easily. Actually, a couple of other SPUs have taken the similar method already into use. It is also possible to define conversion tables between the customized FPA and the original FPA. FUNCTION TYPES OF THE CUSTOMIZED FPA First we had to define the system boundary. It was defined to the (embedded SW) process level, being normally one SW source code file. We wanted to improve definitions of the basic countable items (function types) so that they are more obvious in the SPU's SW archltecture. We investigated for example what is the external input and output in the DX200 SW architecture. We found that the communication over the system boundary is normally done with messages between processes. Internal logicaffiles we replaced by physical files, etc. We examined similarly all FPA function types and we came up with eight basic types in the SPU's SW 'archltecture. They are: master processes, hand processes, other programs, messages, fields, interface routines, MML commands, and MML commarid parameters. Initially we considered more than these eight function types, but in the end we selected those who had the most evident correlation and impact to effort. We were able .to define nearly all function types using existing SPU terminology and definitions,. Thus there was no need for extensive training in this sense. Originally we selected data from 13 SW projects to be used for weight calibration (currently we have a database consisting of dozens of SW projects). We then gathered data and used statistical methods (e.g. regression analysis) to get the basic weights. COMPLEXITY DETERMINATION OF THE FUNCTION TYPES We did not want to increase estimation costs by determining complexity of function types. On the other hand, the 'complexity' is strongly correlated to function types. We have, however, categorized each function type into three classes, depending on whether a new item is created, or an existing item is modified, or an existing item is deleted. ot' Function Point A n u l y s ~ s at Xoklcl Pctri L'c.rc.r~nen . lnd K.irr t \ ; . i i i .~ l . t i.il i